Expo Video Script


Team Introduction
-Madyson: Hello everyone, we are team ASCII RPG and for our Senior Project we decided to make a game titled Boulder Stew.  This is a retro-inspired game that uses a simple letter and number based format to represent the various environments and objects within the world.  It is a comedic adventure that will take you through a variety of varied locales, letting you take in the heavily food based world as you interact with the denizens of places such as Dessert Desert or Cabbage Campo.  We hope that our game will bring some joy into your life and feel like a worthwhile investment of your time to come and see the explorable world we came up with.


Market/Competitors
-Madyson: The idea of making a game based on the aesthetics and design choices of the past is nothing new.  There are plenty of not only Role Playing games but a variety of genres that have been taken back to the past to try to gain the prestige that nostalgia commands.  Specifically, this demographic pertains to a lot of players who were around when the idea of a JRPG came around on the Nintendo Entertainment System.  We appeal to that crowd by having our combat be very similar to that of Dragon Warrior, but also having a very retro look by using the ASCII as our graphics to appeal to those who enjoy games such as Dwarf Fortress or the original Final Fantasy.  This also has the additional benefit that we won’t have to compete with those big names since their games have moved on to have AAA graphics, sound design, and other production values which we are not capable of.
Schedule
-Sydney: Boulder Stew was designed and created over the course of two semesters, Fall 2021 and Spring 2022. Our work style consists of one-to-two-week sprints with weekly to bi-weekly advisor check-ins. Fall 2021 was our primary design period. Early development consisted of researching game design paradigms, creating artifacts, documentation for gameplay design, and NCURSES research. Spring 2022 was our implementation phase of the project. We built a structure consisting of two-week sprints with singular project goals in mind for each. Early goals were building a program skeleton, prototyping of NCURSES, game systems, and planning game progression. Late semester goals were integrating of prototypes, finalizing system features, connecting all system features, gameplay balancing, and story implementation.




Game Mechanics
- Sydney: The major components of the game mechanics are experience points, inventory design, map design, event flags, and incentives to replay certain areas. Experience points work using an experience table with static values for each level up. The player gains an increase in attack, defense, and even new skills or spells at different levels. The inventory system or “Giant Bag of Infinite Holding” allows players to hold as many items as they want in stacks of up to ninety-nine. This ties in with our map design and backtracking incentives. The world consists of a starter area and four connected main zones. Each zone should include an event flag and key item system. Event flags should be tied to NPC encounters that give players hints as to where to explore and fill out the game with content. Key items come from zone bosses and are used to unlock the path to the next area in the game. This is where backtracking incentives really come in; defeating bosses in zones can open new avenues of exploration in previous areas of play. Thus, encouraging players to revisit what they thought were completely explored areas of gameplay.


Project Structure
-Matthew: Our Project is structured to have modular mechanics that can be called with functions and work with the ncurses layout without much hassle. There are many header files that combine with the program to allow data to communicate and pass through multiple files and functions. An example of this is the Hero Class receiving an update to its location whenever the displayed player moves anywhere on the map or is transported to another map. This location is then given to another function when a battle starts to determine which Monster to spawn, each location has its own Monster Table to pull from. This set up with modularity and header files helped our group start working on our individual sections before bringing it all together into a single executable.


Ncurses
-Sydney: While many newer Role-Playing Games have graphics and interfaces that utilize the processing power of modern computers, this game takes things a step back for a classic look and feel. The user interface relies solely on ASCII characters, so there are not any imported art assets or images to the game. The graphics for menu and map interfaces are created using the NCURSES API. This API contains tools that allow us to have functionality for menu traversal, window creation, and color selection.The game consists of three main scenes that make up the user interface: map, inventory, and battle. Using ASCII and tools supplied by NCURSES, we can generate and update menus, logs, and a tile set within the same screen on the terminal for each of these scenes.


ASCII Maps
-Madyson: When it came to the design of our maps, we wanted to emphasize the 80’s retro aesthetic. This was meant to give the players a feeling of nostalgia and simplicity while exploring the world of the game. Our goal was to use low quality graphics to focus on making high quality combat systems, so we decided to use ASCII characters to build our maps. The benefit of using ASCII characters is that we didn’t have the difficulty of designing what the character looks like, or how any of the surrounding area looks, we just used a letter to represent each object. The player gets to do all of the work for us by using their imagination to create intricate sceneries and worlds based on what they think it would look like. We were able to design dungeons, villages, and overworlds just by using ASCII characters to represent objects like mountains, trees, chests, buildings, the sea, and so much more. We hope to remind players that these older games with simple graphics like ours, were the building blocks for the games that we love and play today.


Scrolling Maps
-Matthew: In order to accommodate our different terminal and monitor sizes, we had to come up with a way to scroll the map the player is currently on. This scrolling map feature is able to follow the player wherever they go on the entire map, while also making sure the map doesn’t go off screen in any way. This is especially helpful when dealing with bigger maps that have a greater size than the play window. This scrolling feature was done by creating a camera type object that is bound to the size of the play window. This camera object is given the player’s current x and y location on the map and creates a new location specifically for display purposes. This new displayed position of the player is calculated by checking if the player’s location is less than the half-way point of the camera itself, if it is further than the half-way point of the camera, and if the player is further than the map’s total x and y size subtracted by the camera’s half-way point. Once this is detected it moves both the displayed map and player, keeping the player within view of the play window at all times.


Random Combat
-Benjamin: The defining feature of a lot of the older JRPGS is the presence of random combat.  In modern games, you usually see the enemy on the main map and an encounter starts when your avatar collides with them.  Due to a lack of technology though, in the past this was simply a die roll every time you take a step.  Following this philosophy, we do much the same where every step you take there is a percent chance combat will begin.  Within combat you are given the choice to use moves that your avatar has learnt over the course of the game.  These moves add extra flair to your attacks, doing extra damage or even healing you on top of your normal attack move which uses your avatar’s stats and currently equipped weapon.  Enemies can use these skills too to make for a much more dynamic combat system that allows you to think about what you have to do each encounter.


Inventory Management
-Benjamin: The inventory is designed to be as player friendly as possible. Rather than giving the player a limited amount of inventory space or specific slots for items, they will instead have a giant bag of infinite holding. This lets them stack 99 of any item in their inventory. This is intended to give more player freedom, such as if an enemy is known to drop health potions or some other relevant item and the player chooses to farm said enemy so they can fully stack their inventory with potions they are allowed to do so.  The player is however limited to only having one piece of armor and weaponry equipped at any given time.  This makes them make decisions on whether or not a certain piece is better than another, though we designed the system to announce how their stats change whenever they do an equipment swap.  There are also various stores littered across the world which allow you to purchase consumable items and equipment that can help you in the upcoming battles.


Lessons Learned
-Benjamin: Some of the lessons that have been learned while working on this game the past two semesters include time management as well as expecting things to be much harder to program than they might seem at first glance. It was easy underestimating the difficulty of some of the different aspects of the game engine side, such as getting a camera system for the scrolling map as well as something as simple as transitioning from one map to another. Also, Multi-Dimensional Arrays in C++ can get very complicated.  Another major lesson we learned was how the creative process expands not only to the artistic and narrative side of game development, but also the implementation of the actual code.  Each part of the game is like a puzzle piece that needs to be manufactured and thought of how it will work on its own, then incorporated into the entire game itself.  The number of different approaches that can be taken to designing a battle system, how maps work, or even displaying the GUI are practically endless.  There is also creativity in the process of integration, where different minds may have thought of various ideas on their individual systems, but now those systems have to be fit into a cohesive whole.  There is a level of understanding that must be had with what another teammate may have envisioned and how it will work with all the other sections of code.  That is merely the technical side of things though, game design itself is a creative art form as well.  From the basics of the story, to the aesthetics of how towns and dungeons are laid out, to even conceptualizing the ramp up in difficulty from zone to zone.  These are all things that must be looked at with a creative mindset and put together so the game itself feels like a complete experience.  An experience that takes a TON of time to create and polish, especially without an engine to work with.


Future Plans
-Matthew: We would like to finish some of the features we had originally planned for this game. Some of these features we didn’t have time to implement or just found ourselves struggling with include the event system mentioned earlier where certain tiles or areas of the map could check if a player has a specific key item or flag that allows them to pass through, as well as NPCs that can be spoken to. Another big portion of the game we would like to complete is the less game-engine type stuff, like the silly writing, the story sequences, and the overall balance of the game’s mechanics and combat. We’d also like to make the final location of the game called Spice Sierra, as well as finish implementing the mini-bosses of each zone.